home *** CD-ROM | disk | FTP | other *** search
/ Commodore 64 Scene Diskmags Assortment / Commodore_CEE_Vol._1_Issue_05_1995_Jack_Vander_White_Disk_3_of_3_Side_B.d64 / ace tips 1 < prev    next >
Text File  |  2023-02-26  |  5KB  |  87 lines

  1. Ace uudecode/uuencode
  2.  
  3. From : Steve Craik
  4.  
  5.  Here is an example of what I do:
  6.  
  7.  d:> cp cp uuencode uudecode tr xls more z:
  8.  
  9.   copy all those files into "z:" the ramdrive.  BTW "d:" is my RAMLink. RAMLink's default partition is the partition that all my ACE utilities are located.  PATH is:  d:, z:, m:, b:, c:, a:   (FYI)  but, if the file I want to encode is in another partition in RAMLink other than the default (which happens to be partition #7) then I must include the partition number when I have the various ACE utilities look for the file.   ..well.. lets continue what I do..
  10.  
  11. d:> cd z: z:>
  12.  
  13.    ;the file needed to be uuencoded is in RAMLink partition #4 so
  14.  
  15. z:> uuencode d:/04:filename >filename.uue
  16.  
  17.    ;note the encoded file is in PET and in the "z:" from the file found
  18.    ;in RAMLink (d:) partition #4  (/04:).  It seems that the partition
  19.    ;numbering must be in TWO digit form.
  20.  
  21. z:> tr -p2m filename.uue >filename.asc
  22.  
  23.    ;translated for uploading to IBM BBS and must be i(M)ported into
  24.    ;QWKRR as ASCII.  BUT, the file is in "z:" It needs to be in a
  25.    ;ramlink partition so:
  26.  
  27. z:> cp z:filename.asc d:/04:filename.asc z:> dir d:/04:
  28.  
  29.    ;take a look in partition #4 to see if the file did copy.  NOTE: 
  30.    ;the BYTES *are* different between what you see in the directory of
  31.    ;"z:" ..not to worry.  Somthing in the manner of how ACE stores
  32.    ;files in the ramdisk accounts for this difference.  The PROOF.
  33.  
  34. z:> crc32 z:filename.asc d:/04:filename.asc
  35.  
  36.    ;since partition #7 is still default.. the path statement will let
  37.    ;ACE locate and run "crc32".  Then will display to screen the same
  38.    ;crc's for both files.
  39.  
  40. z:> x
  41.  
  42.    ;exit ACE
  43.  
  44. Load up QWKRR either (E)nter or (R)eply to a message and i(M)port "filename.asc" ..when prompted (A)scii or (P)et..  press "a".
  45.  
  46. DECODING
  47.  
  48.    Say the file is in partition #4 as if you'd downloaded it.  To decode it.  While having copied to "z:" uudecode ..etc.. NOW.. copy the filename into "z:" also.  Lets use "filename.asc" as the example has it.
  49.  
  50. z:> cp d:/04:filename.asc z:   ;filename.asc gets copied to "z:" z:> uudecode filename.asc      ;encoded file is decoded to "z:" z:> cp z:decodedname d:/04:    ;copies to RAMLink partition #4
  51.  
  52. --------------------- ACE REU usage 
  53.  
  54. From : Jim Brain
  55.  
  56.  
  57. Craig mailed me this.
  58.  
  59. <begin quote>
  60.  
  61. Yo!
  62.  
  63. Sorry for taking sooooo long to get back to you...
  64.  
  65. >Care to answer his questions? 
  66. > > BTW what are you using in the way of equipment?  I'm having some >perplexing problems. I have an EXPANDED REU ..1.5meg  RAMLink (8megs) >Total 9.5 I guess you can say.  I'm trying to have ACE detect the 1.5 >megs in DIRECT REU mode.   Doc's say if in direct it ignores >INDIRECT-REU (dacc - 6144 cbm blocks)...and it'll find the REU.. but, >it only finds lists 512k. So I guess it is in FACT ignoring the first >bank/last bank settings in CONFIG.SYS, setup via CONFIG.EDIT. Another >curious thing DOCs say if BOTH first/last have a zero value..then ACE >doesn't use the REU..  I put a low bank value greater than zero and >last bank value greater than the lowbank ..REU ignored.
  67.  
  68. I can't explain the problems with the 1.5 Meg REU; the only problem that I have heard of in the past is the REU being defective.  ACE will "sniff" the entire REU present and should be reporting 1 536K for the REU size.  While sniffing, it stores and tries to retrieve a few bytes onto every bank (while preserving the original contents of those few locations), and it also verifies that bank #0 is still valid (wrap-around).  There is no special case about stopping at 512K in the code, so the only reason why it would be stopping there is a software bug (though I don't think there is one) or one of the tests fails on bank #8 of REU memory, for some hardware reason.
  69.  
  70. For the INDIRECT-REU RAMLink partition, ACE doesn't actually test the REU memory; it just takes on faith what the RL partition info tells it.
  71.  
  72. There are two places in CONFIG.SYS where you set the amount of REU space that ACE is allowed to use; there is a C128 setting and a C64 setting.  You have to set the correct one for which mode/machine you are using.  I have tested ACE Release #11, Release #12, and my current working copy for honouring the first/last REU banks for both C128 and C64 modes and it works perfectly for me.  I expect that your friend is doing something wrong.  One note: where the CONFIG.EDIT program says "last REU bank allowed to use" it should really be saying "last REU bank allowed to use PLUS ONE".
  73.  
  74. >  Oh.. REU in RAM-PORT ..Swiftlink in pass-through port of my RAMLink >and as said previously.. trying to access all this REU in DIRECT.
  75.  
  76. This is the same as my setup, except that I only have a 512K REU (and hence, that is the maximum amount of REU memory that I can test with).
  77.  
  78. > Perhaps the answer is in the use of it in NORMAL. Cause I did notice >that it now shows INDIRECT-REU  1 5.   I was hoping for its use in >DIRECT as it does do things FASTER.   Hmmm?
  79.  
  80. Your friend does, of course, have a non-corrupted copy of ACE, right? (transferred using bcode...).
  81.  
  82. The next release of ACE will be able to access your REU directly even if your NORMAL/DIRECT RL switch is in NORMAL position.
  83.  
  84. ---------------------------
  85.  
  86.  
  87.